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Abstract 


This document describes the general problem of encrypting the Server Name Identification (SND 
TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only 
disclosing the SNI of the fronting service to external observers. This document lists known 
attacks against SNI encryption, discusses the current "HTTP co-tenancy" solution, and presents 
requirements for future TLS-layer solutions. 


In practice, it may well be that no solution can meet every requirement and that practical 
solutions will have to make some compromises. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Not all documents approved by 
the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc8744. 
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reserved. 
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1. Introduction 


Historically, adversaries have been able to monitor the use of web services through three 
primary channels: looking at DNS requests, looking at IP addresses in packet headers, and 
looking at the data stream between user and services. These channels are getting progressively 
closed. A growing fraction of Internet communication is encrypted, mostly using Transport Layer 
Security (TLS) [RFC8446]. Progressive deployment of solutions like DNS over TLS [RFC7858] and 
DNS over HTTPS [RFC8484] mitigates the disclosure of DNS information. More and more services 
are colocated on multiplexed servers, loosening the relation between IP address and web service. 
For example, in virtual hosting solutions, multiple services can be hosted as co-tenants on the 
same server, and the IP address and port do not uniquely identify a service. In cloud or Content 
Delivery Network (CDN) solutions, a given platform hosts the services or servers of a lot of 
organizations, and looking up what netblock an IP address belongs to reveals little. However, 
multiplexed servers rely on the Server Name Information (SNI) TLS extension [RFC6066] to direct 
connections to the appropriate service implementation. This protocol element is transmitted in 
cleartext. As the other methods of monitoring get blocked, monitoring focuses on the cleartext 
SNI. The purpose of SNI encryption is to prevent that and aid privacy. 


Replacing cleartext SNI transmission by an encrypted variant will improve the privacy and 
reliability of TLS connections, but the design of proper SNI encryption solutions is difficult. In the 
past, there have been multiple attempts at defining SNI encryption. These attempts have 
generally floundered, because the simple designs fail to mitigate several of the attacks listed in 
Section 3. In the absence of a TLS-level solution, the most popular approach to SNI privacy for 
web services is HTTP-level fronting, which we discuss in Section 4. 


This document does not present the design of a solution but provides guidelines for evaluating 
proposed solutions. (The review of HTTP-level solutions in Section 4 is not an endorsement of 
these solutions.) The need for related work on the encryption of the Application-Layer Protocol 
Negotiation (ALPN) parameters of TLS is discussed in Section 3.7.1. 


2. History of the TLS SNI Extension 


The SNI extension was specified in 2003 in [RFC3546] to facilitate management of "colocation 
servers", in which multiple services shared the same IP address. A typical example would be 
multiple websites served by the same web server. The SNI extension carries the name of a 
specific server, enabling the TLS connection to be established with the desired server context. 
The current SNI extension specification can be found in [RFC6066]. 


The SNI specification allowed for different types of server names, though only the "hostname" 
variant was specified and deployed. In that variant, the SNI extension carries the domain name 
of the target server. The SNI extension is carried in cleartext in the TLS "ClientHello" message. 
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2.1. Unanticipated Usage of SNI Information 


The SNI was defined to facilitate management of servers, but the developers of middleboxes 
found out that they could take advantage of the information. Many examples of such usage are 
reviewed in [RFC8404]. Other examples came out during discussions of this document. They 
include: 


e Filtering or censoring specific services for a variety of reasons 


e Content filtering by network operators or ISPs blocking specific websites, for example, to 
implement parental controls or to prevent access to phishing or other fraudulent websites 


e ISP assigning different QoS profiles to target services 
e Firewalls within enterprise networks blocking websites not deemed appropriate for work 


e Firewalls within enterprise networks exempting specific websites from man-in-the-middle 
(MITM) inspection, such as healthcare or financial sites for which inspection would intrude 
on the privacy of employees 


The SNI is probably also included in the general collection of metadata by pervasive surveillance 
actors [RFC7258], for example, to identify services used by surveillance targets. 


2.2. SNI Encryption Timeliness 


The cleartext transmission of the SNI was not flagged as a problem in the Security Considerations 
sections of [RFC3546], [RFC4366], or [RFC6066]. These specifications did not anticipate the 
alternative usage described in Section 2.1. One reason may be that, when these RFCs were 
written, the SNI information was available through a variety of other means, such as tracking IP 
addresses, DNS names, or server certificates. 


Many deployments still allocate different IP addresses to different services, so that different 
services can be identified by their IP addresses. However, CDNs commonly serve a large number 
of services through a comparatively small number of addresses. 


The SNI carries the domain name of the server, which is also sent as part of the DNS queries. 
Most of the SNI usage described in Section 2.1 could also be implemented by monitoring DNS 
traffic or controlling DNS usage. But this is changing with the advent of DNS resolvers providing 
services like DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484]. 


The subjectAltName extension of type dNSName of the server certificate (or in its absence, the 
common name component) exposes the same name as the SNI. In TLS versions 1.0 [RFC2246], 1.1 
[RFC4346], and 1.2 [RFC5246], servers send certificates in cleartext, ensuring that there would be 
limited benefits in hiding the SNI. However, in TLS 1.3 [RFC8446], server certificates are 
encrypted in transit. Note that encryption alone is insufficient to protect server certificates; see 
Section 3.1 for details. 
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The decoupling of IP addresses and server names, deployment of DNS privacy, and protection of 
server certificate transmissions all contribute to user privacy in the face of an RFC 7258-style 
adversary [RFC7258]. Encrypting the SNI complements this push for privacy and makes it harder 
to censor or otherwise provide differential treatment to specific Internet services. 


2.3. End-to-End Alternatives 


Deploying SNI encryption helps thwart most of the unanticipated SNI usages, including 
censorship and pervasive surveillance, but it also will break or reduce the efficacy of the 
operational practices and techniques implemented in middleboxes, as described in Section 2.1. 
Most of these functions can, however, be realized by other means. For example, some DNS 
service providers offer customers the provision to "opt in" to filtering services for parental 
control and phishing protection. Per-stream QoS could be provided by a combination of packet 
marking and end-to-end agreements. As SNI encryption becomes common, we can expect more 
deployment of such "end-to-end" solutions. 


At the time of this writing, enterprises have the option of installing a firewall performing SNI 
filtering to prevent connections to certain websites. With SNI encryption, this becomes 
ineffective. Obviously, managers could block usage of SNI encryption in enterprise computers, 
but this wide-scale blocking would diminish the privacy protection of traffic leaving the 
enterprise, which may not be desirable. Enterprise managers could rely instead on filtering 
software and management software deployed on the enterprise's computers. 


3. Security and Privacy Requirements for SNI Encryption 


Over the past years, there have been multiple proposals to add an SNI encryption option in TLS. 
A review of the TLS mailing list archives shows that many of these proposals appeared promising 
but were rejected after security reviews identified plausible attacks. In this section, we collect a 
list of these known attacks. 


3.1. Mitigate Cut-and-Paste Attacks 


The simplest SNI encryption designs replace the cleartext SNI in the initial TLS exchange with an 
encrypted value, using a key known to the multiplexed server. Regardless of the encryption used, 
these designs can be broken by a simple cut-and-paste attack, which works as follows: 


1. The user starts a TLS connection to the multiplexed server, including an encrypted SNI 
value. 


2. The adversary observes the exchange and copies the encrypted SNI parameter. 


3. The adversary starts its own connection to the multiplexed server, including in its 
connection parameters the encrypted SNI copied from the observed exchange. 


4. The multiplexed server establishes the connection to the protected service, which sends its 
certificate, thus revealing the identity of the service. 
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One of the goals of SNI encryption is to prevent adversaries from knowing which hidden service 
the client is using. Successful cut-and-paste attacks break that goal by allowing adversaries to 
discover that service. 


3.2. Avoid Widely Shared Secrets 


It is easy to think of simple schemes in which the SNI is encrypted or hashed using a shared 
secret. This symmetric key must be known by the multiplexed server and by every user of the 
protected services. Such schemes are thus very fragile, since the compromise of a single user 
would compromise the entire set of users and protected services. 


3.3. Prevent SNI-Based Denial-of-Service Attacks 


Encrypting the SNI may create extra load for the multiplexed server. Adversaries may mount 
denial-of-service (DoS) attacks by generating random encrypted SNI values and forcing the 
multiplexed server to spend resources in useless decryption attempts. 


It may be argued that this is not an important avenue for DoS attacks, as regular TLS connection 
attempts also require the server to perform a number of cryptographic operations. However, in 
many cases, the SNI decryption will have to be performed by a front-end component with limited 
resources, while the TLS operations are performed by the component dedicated to their 
respective services. SNI-based DoS attacks could target the front-end component. 


3.4. Do Not Stick Out 


In some designs, handshakes using SNI encryption can be easily differentiated from "regular" 
handshakes. For example, some designs require specific extensions in the ClientHello packets or 
specific values of the cleartext SNI parameter. If adversaries can easily detect the use of SNI 
encryption, they could block it, or they could flag the users of SNI encryption for special 
treatment. 


In the future, it might be possible to assume that a large fraction of TLS handshakes use SNI 
encryption. If that were the case, the detection of SNI encryption would be a lesser concern. 
However, we have to assume that, in the near future, only a small fraction of TLS connections 
will use SNI encryption. 


This requirement to not stick out may be difficult to meet in practice, as noted in Section 5. 


3.5. Maintain Forward Secrecy 


TLS 1.3 [RFC8446] is designed to provide forward secrecy, so that (for example) keys used in past 
sessions will not be compromised even if the private key of the server is compromised. The 
general concerns about forward secrecy apply to SNI encryption as well. For example, some 
proposed designs rely on a public key of the multiplexed server to define the SNI encryption key. 
If the corresponding private key should be compromised, the adversaries would be able to 
process archival records of past connections and retrieve the protected SNI used in these 
connections. These designs fail to maintain forward secrecy of SNI encryption. 
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3.6. Enable Multi-party Security Contexts 


We can design solutions in which a fronting service acts as a relay to reach the protected service. 
Some of those solutions involve just one TLS handshake between the client and the fronting 
service. The master secret is verified by verifying a certificate provided by the fronting service 
but not by the protected service. These solutions expose the client to a MITM attack by the 
fronting service. Even if the client has some reasonable trust in this service, the possibility of a 
MITM attack is troubling. 


There are other classes of solutions in which the master secret is verified by verifying a 
certificate provided by the protected service. These solutions offer more protection against a 
MITM attack by the fronting service. The downside is that the client will not verify the identity of 
the fronting service, which enables fronting server spoofing attacks, such as the "honeypot" 
attack discussed below. Overall, end-to-end TLS to the protected service is preferable, but it is 
important to also provide a way to authenticate the fronting service. 


The fronting service could be pressured by adversaries. By design, it could be forced to deny 
access to the protected service or to divulge which client accessed it. But if a MITM attack is 
possible, the adversaries would also be able to pressure the fronting service into intercepting or 
spoofing the communications between client and protected service. 


Adversaries could also mount an attack by spoofing the fronting service. A spoofed fronting 
service could act as a "honeypot" for users of hidden services. At a minimum, the fake server 
could record the IP addresses of these users. If the SNI encryption solution places too much trust 
on the fronting server, the fake server could also serve fake content of its own choosing, 
including various forms of malware. 


There are two main channels by which adversaries can conduct this attack. Adversaries can 
simply try to mislead users into believing that the honeypot is a valid fronting server, especially 
if that information is carried by word of mouth or in unprotected DNS records. Adversaries can 
also attempt to hijack the traffic to the regular fronting server, using, for example, spoofed DNS 
responses or spoofed IP-level routing, combined with a spoofed certificate. 


3.7. Support Multiple Protocols 


The SNI encryption requirement does not stop with HTTP over TLS. Multiple other applications 
currently use TLS, including, for example, SMTP [RFC3207], DNS [RFC7858], IMAP [RFC8314], and 
the Extensible Messaging and Presence Protocol (XMPP) [RFC7590]. These applications, too, will 
benefit from SNI encryption. HTTP-only methods, like those described in Section 4.1, would not 
apply there. In fact, even for the HTTPS case, the HTTPS tunneling service described in Section 
4.1 is compatible with HTTP 1.0 and HTTP 1.1 but interacts awkwardly with the multiple streams 
feature of HTTP/2 [RFC7540]. This points to the need for an application-agnostic solution, which 
would be implemented fully in the TLS layer. 
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3.7.1. Hiding the Application-Layer Protocol Negotiation 


The Application-Layer Protocol Negotiation (ALPN) parameters of TLS allow implementations to 
negotiate the application-layer protocol used on a given connection. TLS provides the ALPN 
values in cleartext during the initial handshake. While exposing the ALPN does not create the 
same privacy issues as exposing the SNI, there is still a risk. For example, some networks may 
attempt to block applications that they do not understand or that they wish users would not use. 


In a sense, ALPN filtering could be very similar to the filtering of specific port numbers exposed 
in some networks. This filtering by ports has given rise to evasion tactics in which various 
protocols are tunneled over HTTP in order to use open ports 80 or 443. Filtering by ALPN would 
probably beget the same responses, in which the applications just move over HTTP and only the 
HTTP ALPN values are used. Applications would not need to do that if the ALPN were hidden in 
the same way as the SNI. 


In addition to hiding the SNI, it is thus desirable to also hide the ALPN. Of course, this implies 
engineering trade-offs. Using the same technique for hiding the ALPN and encrypting the SNI 
may result in excess complexity. It might be preferable to encrypt these independently. 


3.7.2. Supporting Other Transports than TCP 


The TLS handshake is also used over other transports, such as UDP with both DTLS [DTLS-1.3] 
and QUIC [QUIC]. The requirement to encrypt the SNI applies just as well for these transports as 
for TLS over TCP. 


This points to a requirement for SNI encryption mechanisms to also be applicable to non-TCP 
transports such as DTLS or QUIC. 


4. HTTP Co-tenancy Fronting 


In the absence of TLS-level SNI encryption, many sites rely on an "HTTP co-tenancy" solution, 
often referred to as "domain fronting" [DOMFRONT]. The TLS connection is established with the 
fronting server, and HTTP requests are then sent over that connection to the hidden service. For 
example, the TLS SNI could be set to "fronting.example.com" (the fronting server), and HTTP 
requests sent over that connection could be directed to "hidden.example.com" (accessing the 
hidden service). This solution works well in practice when the fronting server and the hidden 
server are "co-tenants" of the same multiplexed server. 


The HTTP domain fronting solution can be deployed without modification to the TLS protocol 
and does not require using any specific version of TLS. There are, however, a few issues 
regarding discovery, client implementations, trust, and applicability: 


e The client has to discover that the hidden service can be accessed through the fronting 
server. 


e The client's browser has to be directed to access the hidden service through the fronting 
service. 
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e Since the TLS connection is established with the fronting service, the client has no 
cryptographic proof that the content does, in fact, come from the hidden service. Thus, the 
solution does not mitigate the context sharing issues described in Section 3.6. Note that this is 
already the case for co-tenanted sites. 


e Since this is an HTTP-level solution, it does not protect non-HTTP protocols, as discussed in 
Section 3.7. 


The discovery issue is common to most SNI encryption solutions. The browser issue was solved 
in [DOMFRONT] by implementing domain fronting as a pluggable transport for the Tor browser. 
The multi-protocol issue can be mitigated by implementing other applications over HTTP, for 
example, DNS over HTTPS [RFC8484]. The trust issue, however, requires specific developments. 


4.1. HTTPS Tunnels 


The HTTP domain fronting solution places a lot of trust in the fronting server. This required trust 
can be reduced by tunneling HTTPS in HTTPS, which effectively treats the fronting server as an 
HTTP proxy. In this solution, the client establishes a TLS connection to the fronting server and 
then issues an HTTP connect request to the hidden server. This will establish an end-to-end 
HTTPS-over-TLS connection between the client and the hidden server, mitigating the issues 
described in Section 3.6. 


The HTTPS-in-HTTPS solution requires double encryption of every packet. It also requires that 
the fronting server decrypt and relay messages to the hidden server. Both of these requirements 
make the implementation onerous. 


4.2. Delegation Control 


Clients would see their privacy compromised if they contacted the wrong fronting server to 
access the hidden service, since this wrong server could disclose their access to adversaries. This 
requires a controlled way to indicate which fronting server is acceptable by the hidden service. 


This problem is similar to the "word of mouth" variant of the "fronting server spoofing" attack 
described in Section 3.6. The spoofing would be performed by distributing fake advice, such as 
"to reach hidden.example.com, use fake.example.com as a fronting server", when 
"fake.example.com" is under the control of an adversary. 


In practice, this attack is well mitigated when the hidden service is accessed through a 
specialized application. The name of the fronting server can then be programmed in the code of 
the application. But the attack is harder to mitigate when the hidden service has to be accessed 
through general-purpose web browsers. 


There are several proposed solutions to this problem, such as creating a special form of 
certificate to codify the relation between the fronting and hidden server or obtaining the relation 
between the hidden and fronting service through the DNS, possibly using DNSSEC, to avoid 
spoofing. The experiment described in [DOMFRONT] solved the issue by integrating with the 
Lantern Internet circumvention tool. 
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We can observe that CDNs have a similar requirement. They need to convince the client that 
"www.example.com" can be accessed through the seemingly unrelated "cdn-node- 
xyz.example.net". Most CDNs have deployed DNS-based solutions to this problem. However, the 
CDN often holds the authoritative certificate of the origin. There is, simultaneously, verification 
of a relationship between the origin and the CDN (through the certificate) and a risk that the CDN 
can spoof the content from the origin. 


4.3. Related Work 


The ORIGIN frame defined for HTTP/2 [RFC8336] can be used to flag content provided by the 
hidden server. Secondary certificate authentication [HTTP2-SEC-CERTS] can be used to manage 
authentication of hidden server content or to perform client authentication before accessing 
hidden content. 


5. Security Considerations 


This document lists a number of attacks against SNI encryption in Sections 3 and 4.2 and 
presents a list of requirements to mitigate these attacks. Current HTTP-based solutions described 
in Section 4 only meet some of these requirements. In practice, it may well be that no solution 
can meet every requirement and that practical solutions will have to make some compromises. 


In particular, the requirement to not stick out, presented in Section 3.4, may have to be lifted, 
especially for proposed solutions that could quickly reach large-scale deployments. 


Replacing cleartext SNI transmission by an encrypted variant will break or reduce the efficacy of 
the operational practices and techniques implemented in middleboxes, as described in Section 
2.1. As explained in Section 2.3, alternative solutions will have to be developed. 


6. IANA Considerations 


This document has no IANA actions. 
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